

Network-Based Sweepstakes System and Method 



FIELD OF THE INVENTION 



The present invention relates to a system and method for generating traffic at 
Internet websites or other network-based services accessible for on-line communications 
and, in particular, for encouraging users to use a website or other network-based service by 
automatically enrolling users in sweepstakes. 



With the proliferation of Internet websites, a major problem for website providers is 
attracting and retaining Internet users. This problem is of critical importance because 
advertising revenues, which is the major source of revenue for many websites, is often 
linked to the number of users visiting a site and the amount of time users spend on a site. 

One technique used to attract users is to award points for, for example, purchasing 
goods through a website, which may be redeemed for merchandise or other prizes. Such a 
technique is described in U.S. Patent No. 5,774,870 to Storey. One drawback of this 
technique is that it is generally applicable only to websites where goods are sold and 
requires that the website provider have some manner of goods or services to be exchanged 
for points. Another drawback is that many Internet users are reluctant to make purchases 
over the Internet and therefore an award program based on purchases will not attract these 
users. Still another drawback of this technique is that it requires Internet users to actively 
redeem accumulated points, which some users may find bothersome. Another drawback is 
that it requires the Internet provider to provide and support a points redemption program. 



It is therefore an object of the present invention to provide a system and method for 
attracting and retaining Internet users, and users of other network-based services, by 
rewarding users for accessing and using a website, or other feature of a network-based 
service, but without the drawbacks characteristic of the prior art, as mentioned above. 

It is another object of the invention to provide a system and method for operating an 
on-line sweepstakes. 

Briefly, the present invention provides a system and method in which users are 
awarded points, referred to herein as "bones," for accessing a website, and, in particular, for 
clicking on hyperlinks within the website. The number of bones awarded for clicking on 
each hyperlink is stored in a table on the web servers in the host system hosting the website. 
A tally of the number of bones awarded to each user over various periods of time is stored 
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in a database on a database server. Illustratively, these periods are daily, monthly and 
yearly. These tallies are used to automatically enter each user in daily, monthly and yearly 
sweepstakes, awarding substantial cash or other prizes. Users are given an entry in each 
sweepstakes for each corresponding bone and, thus, the more bones that a user accumulates 

5 the more likely he or she is to win any of the sweepstakes. 

When a user signs in to the website, the bone information for that user is retrieved 
by the web server from the database and stored in cookies on the user's PC. A box is then 
displayed on the user's PC stating the user's current number of daily, monthly and yearly 
bones. The web server updates the display in real-time as the user accumulates more bones. 

10 In addition, the web server sends real-time user bone information to the database server so 
that the database server can maintain user bone information independently of the 
information stored in the cookies on the user's PC. In a preferred embodiment, the database 
server periodically transmits (for example, once a day) user bone information to a 
sweepstakes system that conducts the sweepstakes. 

1 5 The present invention thus encourages users to access and use a website by 

awarding bones that give users chances to win sweepstakes. Users are automatically 
enrolled in the sweepstakes and thus are required to take no action other than using the 
website. The invention can be used on any type of website and does not require that the 
website sell a product. It also does not require that the website host provide products or 

20 services as prizes or provide and maintain a point redemption program. 

BRIEF DESCRIPTION OF THE DRAWINGS 

Fig. 1 is a block diagram of an Internet-based sweepstakes system of a preferred 
embodiment of the present invention. 
25 Fig. 2 is a flow chart illustrating a portion of the operation of a preferred 

embodiment of the present invention. 

Fig. 3 is a web page in accordance with a preferred embodiment of the present 
invention. 

30 DETAILED DESCRIPTION 

Fig. 1 illustrates the basic hardware setup of a preferred embodiment of the present 
invention. A user at personal computer (PC) 1 connects, preferably via the Internet, to host 
2. PC 1 contains a processor, such as Pentium II, and memory. Host 2 is comprised of one 
or more web servers 3, such as Netscape Enterprise Webservers. The web servers 3 are in 
35 turn connected to database server 4, containing database 5. Database server 4 is connected, 
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via a dial-up connection, local or wide area network, or other means, to sweepstakes system 
6. 

Briefly, PC 1 contains and executes browser 7, which enables PC 1 to communicate 
with a web server 3, and contains various persistent and transient cookies 8 and 9. Cookies 
5 8 and 9 are set by web server 3; persistent cookies 8 are typically set when a user registers 
with host 2 and transient cookies are typically set when the user subsequently accesses host 
2. Browser 7 and cookies 8 and 9 reside in memory in PC 1. In a preferred embodiment, 
host 2 hosts a portal-type website, i.e., a website that provides hyperlinks to various 
services, various webpages in the website and various other websites and services. When 
10 PC 1 connects to a web server 3, it downloads a webpage, which is displayed by browser 7. 
The webpage contains hyperlinks that are typically highlighted in some manner by browser 
7. When a user selects a hyperlink, by for example clicking on it with his or her mouse, PC 
1 sends a URL (uniform resource locator) corresponding to the hyperlink to webserver 3. 
O In accordance with the present invention, a user is awarded points, referred to herein 

IS 1 5 as "bones," for clicking on hyperlinks. The hyperlinks may represent, in the user's view, a 
N 5 request for a webpage or a portion of a webpage or a request for a service or other feature of 

^ a website. For example, a user may be awarded bones for performing some task, such as 

H making a webpage on host 2 the user's homepage or signing up for a service, such as email. 

™ In this case, the user may have to click on one or more hyperlinks to complete the task, with 

y* 20 the last hyperlink, for example, indicating that the task has been completed. Alternatively, 
^ after the user has completed the task, host 2 can send a redirection response to PC 1, 

causing PC 1 to automatically request a url associated with the completion of the task. 
« Advantageously, different numbers of bones may be awarded for clicking on different 

hyperlinks in accordance with a URL-Bone Table 12. Users are automatically enrolled in 
25 daily, monthly and yearly sweepstakes and their chances of winning depend on the number 
of bones they have collected over the corresponding time period. For security and 
sometimes legal reasons, the maximum number of bones a user can accumulate in a day is 
fixed. In one embodiment, the maximum number is 100. Transient cookies 9 on PC 1 
store the daily, monthly and yearly bone totals. A javascript on PC 1 displays a "bone box" 
30 on PC 1 , containing the user's first name and daily, monthy and yearly bone totals as stored 
in cookies 9. 

Each webserver 3 executes ID cookie module 10 and BCBT (bone counting bone 
tracking) module 11. ID cookie module 10 generates a unique user ID when a user registers 
and writes the ID in a persistent cookie, called ssuid, on PC 1. The unique user ID can be 
35 generated, for example, using Vignette Corporation's StoryServer Software package, which 
guarantees that the ID is specific and unique for each user and produces IDs that are very 
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difficult to generate without using the package (i.e., the IDs are difficult to "spoof). ID 
cookie module 10 also generates a unique user number, associated with each unique user 
ID, and writes the user number in a persistent cookie, called usernum, on PC 1. The 
user_num cookie is used as an index to conveniently access URL-Bone Table 12. 
5 BCBT module 1 1 performs the following functions: 

(a) determines whether the user interacting with the host system is a registered 
user and sets the Register_flag cookie on PC 1 to 'Y' (yes) or C N' (no) accordingly, causing 
the javascript on PC 1 to display a message directing the user to register if he or she is not a 
registered user; 

10 (b) awards a number of bones to a user for requesting a hyperlink, or url, based 

on the number specified in URL-Bone Table 12; 

(c) awards bones to bone counter cookies on the user's PC and asynchronously 
or synchronously writes the number of awarded bones to Database Server 4 (Database 
Server 4 in turn updates user-bones table 5, which stores daily, monthly and yearly bone 

15 information for one or more of the registered users). 

(d) if the daily bone limit for a user has been reached, does not increment the 
bone counter cookies or send awarded bone information for the user to the database; 

(e) writes the user's first name, and daily, monthly and yearly bone totals to 
temporary cookies, called Firstname, Bonecounter_daily, Bonecounter monthly and 

20 Bonecounter_yearly, respectively, which are then displayed in a "bone box" via a javascript 
that executes on PC 1 ; 

(f) writes a special value into the Bonecounterdaily cookie when the system is 
unavailable because the Database Server 4 is transmitting bone information to Sweepstakes 
System 6 (called "bone time"), which in turn causes the javascript on PC 1 to display a 

25 message indicating that bones cannot be awarded at the present time; and 

(g) when an error occurs, writes an error code in an Errorcode cookie on PC 1, 
causing the javascript to display the appropriate error message. 

The BCBT module may be implemented as an NSAPI (Netscape Application 
Programming Interface) plug-in to a Netscape Enterprise Webserver (NES). 

30 Preferably at least once a day, database server 4 sends new user information and 

updated bone information to sweepstakes system 6 for all new users and all users who have 
received bones during the course of the day. If required to satisfy local and federal rules 
and regulations regarding sweepstakes, sweepstakes system 6 may also receive mail-in 
requests for bones via postcards 13 or other alternative means of sweepstakes entry. 

35 Sweepstakes system 6 performs daily, monthly and yearly sweepstakes, with each user 
getting one entry for each of his or her daily, monthly and yearly bones. 
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Fig. 2 is a flowchart illustrating the operation of a preferred embodiment of the 
present invention. In step 3 1 , a user at PC 1 connects to a web server 3 in host 2 by, for 
example, typing a url associated with host 2 in browser 7. In step 32, host 2 executes a 
module that generates a webpage and downloads it to PC 1. In step 33, web server 3 checks 

5 if ssuid and user_num cookies exist for the user by requesting these cookies from PC 1. If 
browser 7 does not have cookies enabled, the user cannot get any bones and PC 1 displays 
an appropriate error message informing the user that cookies must be enabled. As 
mentioned above, the ssuid and user_num cookies are persistent cookies stored on PC 1 
containing a unique user ID and user number, respectively, for a registered user of the 

10 system. If these cookies do not exist, either the user has not yet registered with host system 
2 or the cookies were deleted (for example, because there was a fault in PC 1 or the cookies 
were tampered with). If the user has previously registered, then he signs in at steps 34 and 
35 by entering his user name and password. In step 36, web server 3 verifies the user name 
and password based on the information in password table 13. If the user name and 

15 password is verified, web server 3, in step 37, creates and sets the ssuid, user_num and 
Dblndicator cookies in PC 1. The Dblndicator cookie identifies the database server 4 and 
user_bones table 5 containing information about the user, which is useful if multiple 
databases are used. Otherwise, web server 3 causes PC 1 to report a sign-in error to the 
user, at step 38, and the process returns to step 34. 

20 If the user has not been previously registered, then he registers at step 39. During 

registration, ID cookie module 10 on web server 3 creates an entry for the user in password 
table 13 and creates a unique ssuid and user number for the user. Also, BCBT module 1 1 
creates an entry for the user in a specific database server 4 and user bones table 5. The 
registration process also collects other information about the user, such as the user's age and 

25 address, and determines if the user is eligible to participate in the sweepstakes by, for 

example, checking if the entered age is greater than or equal to 1 8 and the entered address is 
located in a United States state or territory. This information can be carefully verified in the 
event the user wins a sweepstake. Processing then proceeds to step 37, which again creates 
and sets the ssuid and DB Indicator cookies on PC 1 . 

30 Next, in step 40, web server 3 creates and sets the following transient cookies on PC 

1 : Bonecounter_daily, Bonecounter_monthly, Bonecounter_y early, Firstname, 
Registered_flag and Last_url. Bonecounter_daily, Bonecounter_monthly and 
Bonecounter_y early cookies store the current number of daily, monthly and yearly bones, 
respectively. The Firstname cookie stores the user's first name. The bonecounter and 

35 Firstname cookies are retrieved by BCBT module 1 1 from the user_bones table 5 and 

database server 4 identified by the previously set Dblndicator cookie. The Registered_flag 
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cookie is set to c Y 5 (yes) or 'N 5 (no) depending on whether the user is registered. The 
Last_url cookie holds the last url the user went to and is used for fraud detection, as 
explained below. The Last_url cookie preferably expires after 30 minutes; the other 
transient cookies expire when, for example, the user logs off the Internet. 

5 In step 41, a javascript running on PC 1 reads the bonecounter and Firstname 

cookies and displays the user's first name and daily, monthly and yearly bonecounts in a 
box located, for example, at the top of PC l's display screen. 

In step 42, the user clicks on a hyperlink, causing browser 7 on PC 1 to send a url 
request to BCBT module 1 1 on web server 3. Url information may also be sent from a third 

10 party host, not part of host system 2, to BCBT module 1 1 . In this way, a user may receive 
bones for accessing and using websites that are not hosted by host 2. In one 
implementation, the third party host includes an image tag containing a url associated with 
host 2 on each webpage for which bones are awarded; when browser 7 renders the third 
party webpage, it will request the url, which in turn will cause the url to be sent to BCBT 

15 module 1 1 on a web server 3 in host 2. If the user's ssuid and user_num cookies are set, 
BCBT module 1 1 then awards the user the appropriate number of bones and returns an 
image containing the current bonecounts in a bone box, which is then displayed on PC 1 . 
Alternatively, the third party host can display current bonecounts in a bone box via a 
javascript. In another implementation, the third party host can execute its own version of 

20 BCBT module 1 1 that writes user bonecount information to a file, instead of to database 
server 4. The file can then be sent periodically from the third party host to database server 
4, which in turn will update user_bones table 5. 

In step 43, BCBT module 1 1 compares the received url to the url stored in the 
Last_url cookie. If the two are the same, the user does not get any bones for the request and 

25 processing resumes at step 42. This prevents a user from getting credit for, e.g., hitting the 
reload button on his browser. Otherwise, if the received url is different from the url in the 
Last_url cookie, BCBT module 1 1 checks, in step 44, if the daily bone limit has been 
reached by reading the Bonecounter_daily cookie. If it has, processing resumes at step 42. 
If the daily bone limit has not been reached, BCBT module 1 1, in step 45, looks up the 

30 number of bones associated with the url in url-bone table 12 on web server 3. Each entry in 
url-bone table 12 comprises a url (or pathname) and a number of bones associated with the 
url. A master url-bone table is stored on database server 4 and is automatically downloaded 
by each web server 3 whenever a web server starts up. The master url-bone table is also 
periodically downloaded by each web server, for example, once a month, and, the 

35 downloaded url-bone tables are also preferably automatically updated whenever the master 
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url-bone table is updated. A received url is first parsed before the table lookup occurs such 
that all characters after the rightmost slash in the url are removed. 

Finally, in step 46, BCBT module 1 1 determines, based on the Bonecounter_daily 
cookie, if adding the associated number of bones to the user's bone totals will exceed the 

5 user's daily bone limit. If it does not, BCBT module 1 1 adds the associated number of 

bones to the Bonecounter daily, Bonecounter_monthly and Bonecounter_yearly cookies on 
PC 1 ; otherwise, BCBT module 1 1 only adds enough bones to the three bonecounter 
cookies to bring the Bonecounter_daily cookie up to the daily limit. The javascript on PC 
1, in turn, displays the new bone totals in real-time in the user-bone information box. 

10 BCBT module 1 1 also sends the bone information to database server 4, which 

independently updates user_bones table 5. The bone information is sent, in one 
embodiment, asynchronously to reduce the danger that communications between web 
servers 3 and database server 4 will cause a bottleneck, slowing down the performance of 
the overall system. BCBT module 1 1 sends to database server 4 the total number of bones 

15 associated with the url even if it will exceed the user's daily bone limit. Database server 4 
then performs its own determination of whether the daily bone limit for the user will be 
exceeded based on the information in user_bones table 5 and only adds enough bones to 
bring the user up to the daily limit. This determination is performed in two places, BCBT 
module 1 1 in web server 3 and database server 4, to ensure that user_bones table 5 will 

20 store the correct number of cookies even if something goes wrong with the cookie values 
that BCBT module 1 1 uses for its determination. This prevents a user from fraudulently 
obtaining bones by modifying his or her cookie values. 

Database accesses are performed by a database access module executing on database 
server 4. This module may be implemented as a pooled connection design in which each 

25 web server 3 opens a number (for example, 8) connections to database server 4, with the 
final link in each connection implemented using, for example, RogueWave libraries, 
Oracles's Pro*C, OCI and/or Query Cache by Sapient Corporation. The writes to the 
database can be done using asynchronous or synchronous calls to PL/SQL stored 
procedures. Preferably, synchronization points are set up in each web server 3 such that 

30 only one thread can use any one connection to the database at any given time. 

Preferably once a day, during an off-peak time such as the early morning, database 
server 4 transmits to sweepstakes system 6 new user information and daily bone 
information for each user who was awarded one or more bones during the previous twenty- 
four hours. The time that this transmission occurs is referred to as "bone time," and is 

35 programmed into BCBT module 11. If a user accesses host system 2 during bone time, 

BCBT module 1 1 will place a special token in a cookie that specifies that the bone counting 
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system is unavailable. This cookie is read by the javascript on PC 1, which in turn displays 
an appropriate message in the user bone-box on PC 1 . BCBT module 1 1 will come out of 
the bone time state when a flag is set by database server 4 telling BCBT module 1 1 that 
bone time is finished. 

5 Sweepstakes system 6 conducts daily, monthly and yearly sweepstakes in 

accordance with applicable local and federal rules and regulations. Each user automatically 
gets an entry in each daily, monthly and yearly sweepstakes for each of his or her daily, 
monthly and yearly bones. Preferably, the awards for each of the sweepstakes is large 
enough to encourage users to use host system 2. In one embodiment, the daily sweepstake 

10 prize is $10,000, the monthly sweepstake prize is $1,000,000, and the yearly sweepstake 
prize is $10,000,000. 

Fig. 3 is a web page in accordance with an embodiment of the present invention. At 
the top of the page is user bone box 70. Under "Myentries" in the "$10,000 Daily prize" 
subbox 71, "$1 Million Monthly Prize" subbox 72 and "$10 Million Yearly Prize" subbox 
15 73, the -" is replaced by the current number of daily, monthly and yearly bones, 

respectively, once a registered user signs in. In addition, next to each hyperlink, a number 
appears, indicating the number of bones a user will receive for clicking on the hyperlink. 

20 
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